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rd , 
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For 3GPP documents: 
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is equivalent to 

ETSI TS I TR Inn nnn "[Digital cellular telecommunications system (Phase 2+) (GSM);] Universal Mobile 
Telecommunications System; <title> 
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Foreword 



This Technical Specification has been produced by the 3GPP. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of this TS, it will be re-released by the TSG with an identifying 
change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 has been presented to TSG for information; 

2 has been presented to TSG for approval; 

>3 has been presented to TSG for approval and is currently under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the specification; 
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Scope 



The present document establishes and defines the management principles and high level requirements for the 
management of UMTS. 

In particular, the present document identifies the requirements for: 

the upper level of a UMTS Management System; 

the reference model, showing the elements the UMTS Management System interacts with; 

the network operator processes needed to run, operate and maintain a UMTS network; 

the functional architecture of the UMTS Management System; 

the principles to be applied to UMTS Management Interfaces; 

the methodology to be followed in further steps of the UMTS Management Specifications 

The present document does not provide physical architectures of the UMTS Management System. These aspects are 
defined and discussed in more detail in 3G TS 32.102 [101]. 

This document is applicable to all further 3GPP specifications regarding the Network Management of UMTS. 

2 References 

2.1 Normative references 

[1] ITU-T Recommendation M.3010 (1996): "Principles for a telecommunications management 

network" . 

[2] TS 22.101 "Service Principles" 

[3] TS 32. 1 1 1 "3G Fault Management" 

[4] IETF RFC 959 File Transfer Protocol (FTP), October 1985, J. Postel, J. Reynolds, ISI. 

[5] IETF RFC 783 Trivial File Transfer Protocol (TFTP) revision 2, June 1981, K.R. Sollins MIT. 

[6] IETF RFC 1 157 A Simple Network Management Protocol (SNMP), May 1990, J. Case, SNMP 

Research, M. Fedor, Performance Systems International, M. Schoffstall, Performance Systems 
International, J. Davin, MIT Laboratory for Computer Science. 

[7] IETF RFC2401 Security Architecture for the Internet Protocol, IETF, November 1998 

[8] CCITT X.25 (1988): "Interface between Data Terminal Equipment (DTE) and Data Circuit 

Terminating (DCE) for Terminals operating in the Packet Mode and connected to Public Data 
Networks by Dedicated Circuit". 

2.2 Informative references 

[100] NMF GB910. NMF Telecom Operations Map (Evaluation Release Version 1.1 April 1999). 

[101] 3G TS 32. 102 "Telecom Management Architecture" 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following definitions apply: 

Operations System (OS): This abbreviation indicates a generic management system, independent of its location level 
within the management hierarchy. 

Element Manager (EM): Provides a package of end-user functions for management of a set of closely related types of 
network elements. These functions can be divided into two main categories: 

Element Management Functions: for management of network elements on an individual basis. These are basically the 
same functions as supported by the corresponding local terminals. 

Sub-Network Management Functions: that are related to a network model for a set of network elements constituting a 
clearly defined sub-network, which may include relations between the network elements. This model enables additional 
functions on the sub-network level (typically in the areas of network topology presentation, alarm correlation, service 
impact analysis and circuit provisioning). 

Enterprise Systems: those Information Systems that are used in the telecommunication organisation but are not 
directly or essentially related to the telecommunications aspects (Call Centre's, Fraud Detection and Prevention 
Systems, Invoicing etc). 

IRP Information Model: An IRP Information Model consists of an IRP Information Service and a Resource Model 
(see below for definitions of IRP Information Service and Resource Model). 

IRP Information Service: An IRP Information Service describes the information flow and support objects for a certain 
functional area, e.g. the alarm information service in the fault management area. As an example of support objects, for 
the Alarm IRP there is the alarm record and alarm list. 

IRP Solution Set: An IRP Solution Set is a mapping of the IRP Information Service to one of several technologies 
(CORBA/IDL, SNMP/SMI, CMIP/GDMO, etc.). An IRP Information Service can be mapped to several different IRP 
Solution Sets. Different technology selections may be done for different IRPs. 

Management Infrastructure: The collection of systems (computers and telecommunications) a UMTS Organisation 
has in order to manage UMTS. 

Network Element (NE): a discrete telecommunications entity which can be managed over a specific interface e.g. the 
RNC. 

Network Manager (NM): Provides a package of end-user functions with the responsibility for the management of a 
network, mainly as supported by the EM(s) but it may also involve direct access to the network elements. All 
communication with the network is based on open and well standardized interfaces supporting management of multi- 
vendor and multi-technology network elements. 

Resource Model: A protocol independent model describing managed objects representing network resources, e.g. an 
RNC or NodeB. 

UMTS Organisation: A legal entity that is involved in the provisioning of UMTS. 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

CEIR Common Equipment Identification Register 

CPE Customer Premises Equipment 

IRP Integration Reference Point 

MMI Man-Machine Interface 

QoS Quality of Service 

SLA Service Level Agreement 

TM Telecom Management 
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TMF 

TMN 

TOM 

UMTS 

VHE 



TeleManagement Forum 
Telecommunications Management Network 
Telecom Operations Map 
Universal Mobile Telecommunication System 
Virtual Home Environment 



General 



4.1 



UMTS 



4.1.1 Requirements 

The requirements and decomposition of Telecom Management for UMTS do not differ radically from that of 2G 
systems. The following requirements have been identified: 

to be capable of managing equipment supplied by different vendors including the management systems 
themselves. 

to minimise the complexity of UMTS management. 

to provide the communication between UMTS Network Elements and UMTS Operations Systems or between 
UMTS Operations Systems themselves via standardised interfaces (e.g. Q3, CORBA, SNMP, etc.) as appropriate 
and necessary. 

to minimise the costs of managing a UMTS network such that it is a small component of the overall operating 
cost. 

to provide UMTS configuration capabilities that are flexible enough to allow rapid deployment of services. 

to provide integrated Fault Management capabilities. 

to simplify maintenance interventions by supporting remote maintenance operations. 

to allow interoperability between Network Operators/Service Providers for the exchange of 
management/charging information. This includes interoperability with other networks and services (e.g. 
ISDN/B-ISDN, PSTN, and UPT) as well as other UMTS networks. 

to enable the support and control of a growing number of resources. This would allow the system to start from a 
small and simple configuration and grow as needed, both in size and complexity. 

- to re-use existing relevant standards (e.g. GSM. IN, ISDN/B-ISDN, ITU-T, TMF etc.) where applicable 

to support the security management of UMTS (e.g. key management, access control management, operation and 
administration of security mechanisms) with particular emphasis on new features such as automatic roaming and 
packet switched services. 

to provide and support a flexible billing and accounting administration, to support charging across UMTS and 
non-UMTS systems. 

to address the management and assessment of system performance and operation through the use of common 
measurements, etc. This would enable a Network Operator/Service Provider to assess actual performance against 
planned targets. 

to expose any information only once. 

(Example: In case an operator would like to change one parameter in a cell: Then all occurrences of this 
parameter, e.g. transceiver frequency, hand-over relationships, performance measurements, frequency hopping 
control, etc., should be changed by one action only.) 

to support the restoration of a UMTS Operations System (e.g. re synchronisation and atomic transactions). 
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to have one name convention for network resources under management in the 3GPP context. To perform 
network management tasks, co-operating appHcations require identical interpretation of names assigned to 
network resources under management. Such names are required to be unambiguous as well. 

It is acknowledged that the introduction of new architecture to support new services or the introduction of new services 
themselves may impact the detailed requirements of some or all of the above. 

4.1 .2 UMTS Reference Model 

A Universal Mobile Telecommunications System is made of the following components: 

1 or more Access Networks, using different types of access techniques (GSM, UTRA, DECT, PSTN, ISDN,...) 
of which at least one is UTRA; 

1 or more Core Networks; 

1 or more Intelligent Node Networks service logic and mobility management, (IN, GSM...); 

1 or more transmission networks (PDH, SDH etc) in various topologies (point-to-point, ring, and point-to-multi- 
point...) and physical means (radio, fibre, and copper...). 

The UMTS components have signalling mechanisms among them (V5, A, DSSl, INAP, MAP, #7, RSVP,...). 

From the service perspective, the UMTS is defined to offer: 

Service support transparent to the location, access technique and core network, within the bearer capabilities 
available in one particular case; 

User to terminal and user to network interface (MMI) irrespective of the entities supporting the services required 
(VHE); 

Multimedia capabilities. 

4.1.3 UMTS Provisioning Entities 

The specification 22.101 "Services Principles" [2] identifies two major entities which cover the set of UMTS 
functionality's involved in the provision of the UMTS services to the user. These are: 

Home Environment: This entity holds the functionality's that enable a user to obtain UMTS services in a consistent 
manner regardless of the user's location or the terminal used; 

Serving Network: This entity provides the user with access to the services of the Home Environment. 

4.1 .4 UMTS Management Infrastructure 

Every UMTS Organisation has it's own Management Infrastructure. Each Management Infrastructure will contain 
different functionality depending on the role played and the equipment used by that UMTS Entity. 

However the core management architecture of the UMTS Organisation is very similar. Every UMTS Organisation: 

- provides services to it's customers; 

needs an infrastructure to fulfil them (advertise, ordering, creation, provisioning, ...); 
assures them (Operation, Quality of Service, Trouble Reporting and Fixing, ...); 

- bills them (Rating, Discounting, ...). 

Not every UMTS Organisation will implement the complete Management Architecture and related Processes. Some 
processes may be missing dependent on the role a particular UMTS Organisation is embodying. Processes not 
implemented by a particular UMTS Organisation are accessed via interconnections to other UMTS organisations, which 
have implemented these processes (called X-interfaces in the ITU-T TMN architecture). 

The Management architecture itself does not distinguish between external and internal interfaces. 
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4.2 ITU-T TMN 

ITU-T TMN (Telecommunications Management Network standard from the International Telecommunications Union), 
as defined in [1], provides: 

an architecture, made of OS (Operations Systems) and NEs (Network Elements), and the interfaces between 
them (Q3, within one Operator Domain and X, between different Operators); 

the methodology to define those interfaces; 

other architectural tools such as LLA (Logical Layered Architecture) that help to further refine and define the 
Management Architecture of a given management area; 

a number of generic and/or common management functions to be specialised/applied to various and specific 
ITU-T TMN interfaces. 

The UMTS Management Architecture is based on ITU-T TMN, and will reuse those functions, methods and interfaces 
already defined (or being defined) that are suitable to the management needs of UMTS. However, the UMTS 
Management needs to explore the incorporation of other concepts (other management paradigms widely accepted and 
deployed) since: 

UMTS incorporates other technologies to which ITU-T TMN is not applied fully; 

UMTS faces new challenges that ITU-T TMN does not address today; 

The ITU-T standards are mainly concentrated in the element management and network management layers. 
They have been developed from the bottom up, making it difficult to apply the standards as part of a business 
case. It is also difficult to have a customer centric focus. 

An example of another management paradigm that will be employed to try and address these difficulties is 
the Telecom Operations Map from TeleManagement Forum (TMF). The Telecom Operations Map, using the 
TMN model as a foundation, addresses operation support and management for any communications service 
from a top down customer oriented standpoint. 

It must be noted that these concerns are applicable to other telecommunication areas as well as to UMTS, it is expected 
that the eventual evolution of ITU-T TMN will cover this ground. Indeed, most of the above concepts are already being 
taken into account by ITU-T TMN evolution (protocols and methodologies). 



5 Architectural Framework 

5.1 UMTS Management Reference Model & Interfaces 

Figure 1 illustrates the UMTS Management Reference Model. It shows the UMTS Operation System interfacing with 
other systems. 

This specification (and the rest of the 3GPP UMTS Management detailed specifications) addresses the UMTS 
Operations System (function and architecture wise) and the interfaces to the other systems (information and protocol 

wise). 

This specification does not address the definition of any of the systems which the UMTS Operations System may 
interface to. The rest of the 3GPP specifications regarding UMTS Management will not cover them either. 

It is not the approach (nor it is possible) to re-define the complete management of all the technologies that might be 
used in the provision of UMTS. However, it is the intention to identify and define what will be needed from the 
perspective of UMTS management. 

A number of management interfaces in a UMTS network are identified in figure 1, namely: 

CD between the NEs and the Opeartions System of a single UMTS Organisation 

a) network element to element management level 
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b) element management to network management level 
(2) between the Operations System and the Enterprise Systems of a single UMTS Organisation. 
® between Operations Systems of different UMTS Organisations 
(£) within the Operations System of a single UMTS Organisation 

This specification will focus on management interfaces of type 1 from the above list, while interfaces of types 2 & 3 
will be identified in this document, detailed specification of these interfaces is FFS. Interfaces of type 4 are beyond the 
scope of standardisation. 

NOTE: Both TeleManagement Forum and ITU-T are carrying out work with interfaces of type 3. 



UMTS Organisation A 



Enterprise 
Systems 




s ime re le 



UMTS Operations 
System 



¥ 



Network 
Elements 



o:her re le 



Organisation B 



Operations 
System 



Figure 1 : UIVITS IVIanagement System interactions 



5.2 Interfaces to Enterprise Systems (Type 2) 

It is the approach to define a UMTS Management that fully fits into the enterprise processes needs of the UMTS 
Organisations. One of the essential issues of today's way of running telecommunications businesses is integral operation 
(e.g.: customer care, from service subscription to billing, from order fulfilment to complaint management). 

Enterprise Systems are those Information Systems that are used in the telecommunication organisation but are not 
directly or essentially related to the telecommunications aspects (Call Centre's, Fraud Detection and Prevention 
Systems, Invoicing etc). 

Standardising Enterprise Systems is out of the scope of 3GPP work, since it involves many operator choices 
(organisational, etc) and even regulatory. Also Enterprise Systems are often viewed as a competitive tool. However, it is 



ETSI 



(3G TS 32.1 01 version 3.0.0 Release 1 999) 1 2 eTSI TS 1 32 1 01 V3.0.0 (2000-01 ) 

essential that the requirements of such systems are taken into account and interfaces to the UMTS Operations Systems 
are defined, to allow for easy interconnection and functional support. 

5.3 Interfaces to NEs (Type 1 ) 

In some cases, the management interfaces to NEs have been defined bottom-up, trying to standardise the complete 
O&M functionality of the various NEs. 

For UMTS management, a top-down approach will be followed to streamline the requirements from the perspective of 
UMTS Operators top priority management processes. 

It is assumed that this will not fully cover the OAM functionality of all NE types in UMTS at once, therefore a part of 
the functionality will be phased for further work and consideration. Some proprietary solutions (local and/or remote) 
will be needed in the interim. The rational of this approach is not only the best use of resources, but also to follow a 
pragmatic step-wise approach that takes into account the market forces (the manufacturers and operators capabilities). A 
further rational is to define clear and easy to agree steps that allow Management functionality to be implemented in the 
same time frame as the telecom functionality in the network (i.e. to synchronise the management and network releases). 

The approach for NE Management Interfaces will be to concentrate on protocol independent information models, 
allowing a mapping to several protocol suites. The rational is: 

due to the convergence of Information and Telecommunication technologies in UMTS, It is required to work on 
a more open approach (acknowledging the market status and foreseen evolutions); 

the life-cycle of information flows is 10 to 20 years, while that of protocols is 5 to 10 years; 

developments in automatic conversion from information models to various protocols/technologies will allow a 
more pragmatic and open approach (e.g. UML to GDMO, UML to IDL). 

However, it is the intention to a least recommend one mapping for each interface. 

5.4 Interfaces to other Operations Systems (Type 3) 

UMTS Management considers integrally the interaction between the Operations Systems of other legal entities for the 
purpose of providing UMTS services. 

There are two major types of interfaces to other management systems: 

to other UMTS Operations Systems (i.e. other from other UMTS operators); 

to other Operations Systems (i.e. to non UMTS operators). 

The first type deals with co-operation to provide UMTS services across a number of UMTS networks (e.g. roaming 
related interactions). The second type deals with client-server relationship to other operators (e.g. to leased lines 
providers, to added value service providers etc). 

The approach that will be followed is to identify and define integral processes, not taking into account in the first step, 
how many operators or operations systems might be involved, but rather concentrating on the interactions between them 
(i.e. assuming a UMTS operator encompasses all functionality's). A further step will be to consider and define extra 
requirements (security, confidentiality etc) when part of the process involves interactions with other operators 
operations systems. 

5.5 Interface Definition 

The Management interfaces are studied here from four different perspectives or levels: 

logical (information model and flows used in the relationship manager-agent, or equivalent); 

application protocol (end to end, upper layers protocol running between manager-agent, or equivalent); 

networking protocol (lower layer protocols carrying the information in/out the manager and agent, or 
equivalents); 
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- physical (mapping of the manager and agent, or equivalents, roles into physical entities). 

The figure below shows the management interfaces of one part of the UMTS (The Radio Network), by way of 
illustration of interfaces of types la and lb). 



Network Manager 
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Itf-N 
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Manager 
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Element 
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\ 






NodeB 
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Figure 1.1 : Radio Network lUlanagement Interfaces 

The figure identifies the following Management Interfaces: 

Itf-B - between Node B & its Manager (physically, this may be a direct connection or via the RNC) (type la) 
- Itf-R - between RNC & its Manager (type la) 

Itf-N - between Network & Network Manager (type lb) 



5.6 Logical Level 



This level covers the mutual and conceptual knowledge of entities being connected by a given interface. 

For type lb interfaces (such as Itf-N in figure 1.1 above) interactions at this level are fully standardised by 3GPP in 
terms of protocol independent Resource Models (static information definition) and IRP Information Services 
(information flows) where available. These protocol independent Resource Models and IRP Information Services are 
hereafter referred to as IRP Information Models (Integration Reference Point Information Models). 

For type la interfaces (such as Itf-B and Itf-R in figure 1.1 above) interactions at this level are not standardised in terms 
of information models or flows, though functional aspects will be specified. 



5.7 



Solution set Level 



For each IRP Information Model at the logical level there will be at least one IRP Solution Set defined. An IRP Solution 
Set is a mapping of the IRP Information Service to one of several technologies ( for a full definition please refer to the 
definitions clause of the present document). 

See Annex C for the valid UMTS Management IRP Solution Sets. 
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5.8 Application Protocol Level 

This level covers the set of primitives used to pass information across a given interface and the means to establish 
associations between the application entities (including the related addressing aspects) across a given interface. 

Generally, the Application Protocol Suite used for the interaction between entities across a given interface is optional 
within the valid UMTS Management Application Protocol Suites (see Annex A for a list of UMTS Management 
Protocol Suites). However, in the case of interfaces of type lb (such as Itf-N in figure 12 above) at least one of those 
protocol suites will be chosen as the standard protocol suite. 

It is the intention to consider following attributes of each application protocol in making this decision: 

CMIP: 

Very flexible; 

Powerful information modelling capability, therefore, in turn, complex to implement; 

Complex to integrate managers (specifically if CMIP stacks from different vendors are used in the agents and 
manager(s)); 

Process hungry; 

Heavyweight stack (e.g. prevents it from being implemented on NodeB); 

Potential reuse of GSM and ITU-T standards and implementation; 

High on Cost Of Goods. 

SNMP: 

is well used in other Telecom areas (e.g. ATM management); 

has inadequacies for Configuration Management (relatively simple/poor information modelling capability for 
management MIBs make implementation of complex information models difficult, although not impossible); 

supports auto-discovery of elements on the management network via MIB-II; 

has lower Cost Of Goods; 

more choice of "off the shelf commercial systems and software" section 7.2 ref [101]. 

CORBA-IIOP: 

very powerful and flexible 

low Cost Of Goods 

not proven in Telecom Management (but gaining acceptance) 



5.9 Networking Protocol Level 



Whatever standardised protocol suite at the networking level that is capable of meeting the functional and operational 
requirements (including the network addressing aspects) of the Logical and Application Protocol levels of a given 
UMTS management interface, is a valid Networking Protocol for that interface. 

A number of requirements shall be met by the Networking Protocol, as follows: 

capability to run over any bearer (leased lines, X.25, ATM, Frame Relay, ...); 

support of existing transport protocols and their applications, such as OSI, TCP/IP family, etc; 

widely available, cheap and reliable. 
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The Internet Protocol (IP) is a Networking Protocol that ideally supports these requirements. IP also adds flexibility to 
how management connectivity is achieved when networks are rolled out, by offering various implementation choices. 
For instance, these may take the form of: 

Dedicated management intranets. 

Separation from or integration into an operator's enterprise network. 

Utilisation, in one way or another, of capacities of the public Internet and its applications or other resources. 

5.10 Physical Level 

Though the interaction at the logical level takes place between the UMTS Management System and the UMTS NEs, it 
is left to the implementers choice the possibility to use the Q- Adapter^ concept of ITU-T TMN Architecture as physical 
implementation (as defined in [1]). 

The present document does not preclude the usage of Q-Adapters at other interfaces of the UMTS Management. 

5.1 1 Compliance Conditions 

For a UMTS entity (Management System or NE) to be compliant to a given UMTS Management Interface, all the 
following conditions must be satisfied: 

it implements the management functionality following the Information Model and flows specified by the 
relevant 3GPP UMTS Management Interface Specifications applicable to that interface; 

it provides at least one of the IRP Solution Sets (where available) related to the valid Application Protocols 
specified by 3GPP UMTS Application Protocols for that interface (see Annex A). For each interface at least one 
of the valid protocols will be recommended; 

it provides at least one standard networking protocol; 

in case the entity does not offer the management interface on its own, a Q-Adapter must be provided. This Q- 
Adapter must be provided independently of any other UMTS NE and/or UMTS Management System. 



UIVITS IVIanagement Processes 



This document details the general aspects of a UMTS Management system. It describes primarily the management 
processes that collectively support Customer Care Service Development & Operations, and Network & Systems 
Management Processes in a UMTS network. 

These management processes are based on the widely accepted Telecom Operations Map from the TeleManagement 
Forum [100]. They map onto the Service and Network Management layers as defined in the ITU-T Recommendation 
M.3010 appendix II [1] as depicted in Fig.2 below. 



Q-Adapter needs to be interpreted here in a wider sense than in [1], since UMTS will consider other application protocols different to CMIP 
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Figure 2: Telecom Operations lUlap Business Process IVIodel (* imported from [100]) 

(Service & Network Management shading added in this document) 

This Technical Specification will detail the UMTS Management Functional Architecture. This will be done by applying 
each of the management functions to the UMTS management processes. 

The management functions are: 

fault management; 

configuration management (including equipment inventory); 

- performance management (including quality of service management); 

- roaming management ; 

- accounting; 

customer profile management; 
service deployment; 
fraud management; 

- security management 
software management 
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All UMTS management processes have functions in several management areas. By identifying only those processes and 
interfaces relating to a certain management function, for example performance management, it is possible to take a slice 
through the Telecom Operations Map that details the functional architecture for performance management, this will be 
the approach taken by this Technical Specification. 



7 Process Decompositions 

This clause gives a short description of each of the UMTS management processes introduced in [100]. To see a more 
detailed description and process spider diagram for each process please refer to [100]. 

7.1 Customer Interface IVIanagement 

The Customer Interface Management Process directly interacts with customers and translates customer requests and 
inquiries into appropriate "events" such as, the creation of an order or trouble ticket or the adjustment of a bill. 

7.2 Sales 

The Sales Process encompasses learning about the needs of each customer, and educating the customer about the 
communications services that are available to meet those needs. 



7.3 Ordering 



The Ordering Process includes all the functions of accepting a customer's order for service, tracking the progress of the 
order, and notifying the customer when the order is complete. 

7.4 Problem Handling 

The Problem Handling Process is responsible to receive service complaints from customers, resolve them to the 
customer's satisfaction and provide meaningful status on repair or restoration activity. 

7.5 Customer QoS Management 

This process is concerned with UMTS Quality of Service (QoS) and its measurement, management and reporting. 



7.6 Invoicing and Collection 



This process encompasses sending invoices to customers, processing their payments and performing payment 
collections. 

7.7 Service Planning and Development 

This process encompasses: 

designing technical capability to meet specified market need at desired cost; 

ensuring that the service (product) can be properly installed, monitored, controlled, and billed; 

initiating appropriate process and methods modifications, as well as initiating changes to levels of operations 
personnel and training required; 

initiating any modifications to the underlying network or information systems to support the requirements; 

- performing pre-service testing that the technical capability works and that the operational support process and 
systems function properly; 
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ensuring that sufficient capacity is available to meet forecasted sales. 

7.8 Service Configuration 

This process encompasses the installation and/or configuration of service for specific customers, including the 
installation/configuration of customer premises equipment. 

7.9 Service Problem Resolution 

This process encompasses isolating the root cause of service affecting and non-service affecting failures and acting to 
resolve them. Typically, failures reported to this process affect multiple customers 

7.1 Service Quality IVIanagement 

This process supports monitoring service or product quality on a service class basis in order to determine 
whether service levels are being met consistently; 
whether there are any general problems with the service or product; 
whether the sale and use of the service is tracking to forecasts. 

7.1 1 Rating and Discounting 

This process encompasses: 

applying the correct rating rules to usage data on a customer-by-customer basis, as required; 
applying any discounts agreed to as part of the Ordering Process; 
applying promotional discounts and charges; 

- applying outage credits; 

applying rebates due because service level agreements were not met; 

- resolving unidentified usage. 



7.12 Network Data IVIanagement 



In general, this process is responsible for the collection of performance/usage data and events for the purpose of 
network performance, usage and traffic analysis. This data is also an input to the Rating and Discounting process at the 
Service Management Layer. 

7.13 Network Maintenance & Restoration 

This process encompasses maintaining the operational quality of the network, in accordance with required network 
performance goals. 

Note: 3GPP have added an additional process flow to this process. For this reason a modified spider diagram for this 
process is included below (changes highlighted in red), this change has been submitted to TMF for inclusion in the 
Telecom Operations Map (TOM), when the changes is incorporated in the TOM the diagram can be removed from this 
document. 
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NOTE: Red colours in the figure above indicate changes to Telecom Operations Map not yet approved by TMF. 
Figure 3: Networl< IVIaintenance and Restoration Process 

7.14 Network Inventory Management 

This process encompasses anything to do with physical equipment and the administration of this equipment. 

7.15 Network Provisioning 

This process encompasses the configuration of the network, to ensure that network capacity is ready for provisioning of 



7.16 Network Planning and Development 

This process encompasses development and acceptance of strategy, description of standard network configurations for 
operational use, definition of rules for network planning, installation and maintenance. 



8 UMTS Management Functional Architecture 



8.1 TM Architectural aspects 



The basic aspects of a TM architecture, which can be, considered when planning and designing a TM are 

the functional architecture; 

the information architecture; 

the physical architecture. 

The management requirements from the business needs will the base for the functional architecture, which will describe 
the functions that have to be achieved. The information architecture defines what information that has to be provided so 
the functions defined in the functional architecture can be achieved. The physical architecture has to meet both the 
functional architecture and the information architectures. These relationships are shown in figure 4 below. 

This document addresses the Functional Architecture, the Physical Architecture is addressed in [101]. 
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Figure 4: Architectural relationship 



8.2 Performance Management 



Figure 5 below makes a cut through the Telecom Operations Map from a Performance Management perspective. 
Although this "cut slice" is quite large it does not contain all and everything related to Performance Management. But it 
contains all processes and interfaces mainly involved in Performance Management. To make the figure clearer different 
thicknesses of lines have been used to illustrate the different importance of the accordingly marked interfaces. 
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8.3 Roaming Management 



This example describes a unique, for mobile networks, management task. Roaming is a service provided by mobile 
service providers where customers of a home service provider may use the infrastructure of another, a serving service 
provider (see figure 6). The idea is that a customer receives the same service when it roams in another network, as it 
would receive at home. 
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Figure 6: Relationships between Subscriber, Home and Serving Service Provider 

In order to make this happen, the home service provider and serving service provider need a contractual relationship 
called a roaming agreement. The roaming agreement can be an ordinary direct agreement between both service 
providers or it can be established by the means of a clearinghouse. 

In any case the roaming agreement regulates at least the following items: 

tariffing and pricing; 

signalling and traffic interconnection; 

CDR exchange format and exchange schedule; 

- problem handling; and many others. 

Today's mobile networks have roaming agreements with tens of other networks. With ^"^ Generation mobile networks 
coming this number is expected to increase to hundreds if not more. All these roaming agreements have an impact on 
many parts of the network. 

The handling of this complex process requires an excellent understanding of roaming agreement management. To aid 
this understanding figure 7 below is provided. All information flows, which are not effected or not changed by roaming 
agreement management, have been omitted to aim readability. 

Note: The information flows shown in figure 7 are intended to illustrate the flow of management information 
required to support roaming in 3"* Generation networks. 

The information flow illustrated below is an overlay onto the main information flow of a serving mobile service 
provider to support it's own subscribers. This overlay information flow of the serving service provider is triggered by 
the request to establish or update a roaming agreement issued by the customer. 

In this context the home service provider is classified as a customer of a serving service provider (customer in this 
context does not refer to an individual customer of the home service provider!). 

The home service provider (customer) would like to offer roaming to the serving service provider to its subscribers. 

The roaming agreement management information flow consists of one major and two optional supporting information 
flows: 

customer care information flow (solid line) 

This is the major information flow supporting all contract related activities: negotiating tariffs, negotiating SLAs, 

trouble handling, roaming accounting file exchange, ... 

new service facilities information flow (dash-dotted line) 

This is an optional supporting flow which takes place if the support of an roaming agreement requires the 

introduction of new services or a configuration change of existing services. 

new network facilities information flow (dashed line) 

This is an optional supporting flow which takes place if the support of an roaming agreement requires the 

introduction of new network facilities or a configuration change of existing network facilities. 
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Figure 7: Information flow to support Roaming Management 



8.4 Fraud Management 



Fraud and all the activities to detect and prevent fraud are quite common for most of the networks. Nonetheless it 
should be mentioned that two mobile network specific services: mobility and roaming make fraud detection and fraud 
prevention even more complicated: The mobile service provider does not know where is the "end of the wire" leading to 
the home of a fraudulent customer. In case of roaming the situation is even worse. The fraudulent customer uses the 
network facilities of another - the serving - service provider which means that it is to a large extent out of control of the 
home service provider. 

Typically fraud management in mobile networks (i.e. fraud detection and prevention) covers at least the following 
functions: 

classification of customers according to levels of fraud risk (based on demographic and credit information); 

- revision of the fraud risk level (based on usage information, payment behaviour, ... near real time or off-line); 

detection of fraud patterns (in real time or near real time); 

taking the appropriate actions to suspend service provision, even if the customer is using a different network than 
its home (the customer is roaming); 

for visiting customers (i.e. those who are roaming) it may consult the home provider and/or international 
repositories (e.g. the Central Equipment Identity Register - CEIR for GSM mobile equipment). 
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Fraud management is present in several processes of the Telecom Operations Map. Figure 8 below shows the 
occurrence of fraud detection and fraud prevention functions listed above to the existing processes of the Telecom 
Operations Map. 
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Figure 8: Information flow to support Fraud Management 

Fraud management functions are present in many processes of the Telecom Operations Map. What makes fraud 
management so difficult is the fact that it consists of many process flows segments instead of one or two continuous 
process flows. This is also the reason making the presentation of fraud management in the Telecom Operations Map so 
difficult. 

Although it seems that all required functions to support fraud management exist in the Telecom Operations Map, fraud 
management requires the introduction of some new interfaces (marked accordingly in figure 8) to be efficient. 

Pre service: prevent fraud 

Potential threats and leaks should be analysed during Service Planning and Design and the service should be 
optimised to be as resistant to threats as possible. 

Fulfilment: prevent fraud 

Order Handling initiates the classification of customers according to levels of fraud risk. This includes a 
credit check request; and 

- A retrieval of fraud information from a fraud prevention pool (if available). 
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The determined initial fraud risk level will be registered at Problem Handling. 

A credit line depending on the customer's fraud risk level will be registered at Rating & Discounting. 

- Finally the ordered Service will be activated fully or partly depending on the fraud risk level. 
Assurance 1 : detect fraud 

- Normal usage data (preferably hot billing usage data) is transferred to Rating and Discounting. 

Rating & Discounting checks billing records for exceeding established credit lines and reports this Problem 
Handling (new). 

Assurance 2: detect fraud 

Usage data/patterns are sent to the Customer QoS Management for analysis. 

If Customer QoS Management detects a fraud then it sends an according notification to Problem handling 
which can decide on appropriate actions to take in order to prevent or stop fraud. 

Assurance 3: detect fraud 

Treasury informs Problem handling about the payment behaviour of customers. 

Assurance 4: stop fraud 

Problem Handling can decide on appropriate actions to take in order to prevent or stop fraud by reconfiguring 
the service; and/or 

contacting via Customer Interface Management 

The Customer (either the end-customer or the home service provider in case of a visiting customer). 
Assurance 5: prevent fraud 

Problem handling may register fraud information in the Fraud Prevention Pool. 

Assurance 6: stop roaming fraud 

Problem handling requests the monitoring of a visiting customer on a trouble notification request of its home 
service provider according to the roaming agreement. 

- Network Data Management delivers the usage data to the requesting home service provider. 



8.5 Fault Management 



Fault Management is accomplished by means of several Processes/Sub-processes like fault detection, fault localisation, 
fault reporting, fault correction, fault repair, etc... These Processes/Sub-processes are located over different 
management layers, however, most of them (like fault detection, fault correction, fault localisation and fault correction) 
are mainly located over the Network Element and Network Element Management layers, since this underlying network 
infrastructure has the 'self healing' capabilities. 

It is possible, however, that some faults/problems affecting the telecom services are detected within the "Network and 
Systems Management" layer, by correlating the alarm/events (originated by different Network Elements) and 
correlating network data, through network data management. 

Network data management logically collects and processes both performance and traffic data as well as usage data. 

While the fault management triggered within the Network Element and NE Management layers is primarily reactive, 
the fault management triggered within the Network and Systems Management layer is primarily proactive, meaning 
triggered by automation rather than triggered by the customer, and this is important for improving service quality, 
customer perception of service and for lowering costs. 

Focusing on the Network and Systems Management layer, when a fault/problem is detected, no matter where and how, 
several processes are implicated, as described in figure 9 below. 
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8.5.1 Telecom Operations Map. 



The diagram below taken from the Telecom Operations Map [100] shows an example of how fault management data 
can be used to drive an operators service assurance process. Service assurance then becomes primarily proactive, i.e. 
triggered by automation rather than triggered by the customer. It is argued that this approach is key to improving service 
quality, customer perception of service and for lowering costs. 
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Figure 9: Service Assurance Process Flow (* imported from [100]) 

TOM assurance activities (and their associated interfaces) shown in figure 9 above can be associated with ITU-T TMN 
service components from [3] according to the following table: 



ITU-T TMN Service Component [3] 


TOM Network Management Assurance Activities 


Alarm Surveillance 


Detect Fault 


Fault Localisation 


Isolate Root Cause 


Fault Correction 


Decide Repair / Allocate Resources 


Testing 


Test 



The TOM assurance example shown in figure 8 also recognises that Performance Management data can also be used to 
detect network problems. 

The TOM assurance example also adds some detail to the Service Management Layer by showing how activities such 
as determining and monitoring SLA's (Service Level Agreements) and trouble ticket reporting are interfaced to the 
Network Management layer. 

8.5.1 General Requirements, Service Components and Functions 

Fault Management service components and functions are an area well documented by existing ITU-T, ETSI and other 
standards. The GSM Specification GSM 12.11 (Fault Management of the Base Station System) provides a 
comprehensive explanation and specification of the relevant ITU-T TMN standards. This has been used as a basis for 
the 3G specification 3G TS 32. Ill . 

3G TS 32. 1 1 1 is based on the following service components: - 
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alarm surveillance; 

- fault localisation; 
fault correction; 

- testing. 

Please refer to [3] for complete details. 

8.6 Security Management 

This section describes an architecture for security management of the TMN that is divided into two layers, as shown in 
Figure 10. No individual layer is dependent on any specific technology in the other one. 
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Figure 10 Security IVIanagement Architecture 



8.6.1 Layer B - O&M IP Network: 



Some Service Providers might build their O&M IP network as a completely private, trusted network. In the normal case 
though, the O&M IP network should be regarded as partly insecure due to its size, complexity, limited physical security 
and possible remote access from dial-up connections or from the Internet. The only security service provided then is 
that the O&M IP network is logically separated from the Internet. IP infrastructure aspects on security are handled to 
the extent possible utilizing IP classic features (addressing schemes, DNS, DHCP, BOOTP, protection with firewalls 
etc.). 

Additionally, a trusted IP-environment to the application level might be provided, e.g. an environment with no 
masquerading IP-hosts and where potential intruders can not communicate. One way to accomplish such a secure DCN 
is to use IP security mechanisms (IPSec, see [7]) to achieve authentication of IP hosts (servers, gateways, network 
elements) and optional encryption of O&M traffic. Note however that the secure DCN does not authenticate users. 



8.6.2 Layer A - Application Layer: 



On this layer we find Telecom Management applications performing their tasks in the normal management functional 
areas. Managed objects residing in the network resources are often accessed or manipulated. 

Layer A provides authentication of users ensuring that every party involved in O&M traffic is securely authenticated 
against every other party. The implementation of the authentication service supports "single log-on" (a user only has to 
log-on once to get access to all O&M applications in the network) and "single point of administration" (an administrator 
only needs to maintain a user and his/her profile in one place). 

Layer A also provides authorization (access control) - to verify if a user is authorized to perform a certain operation 
upon a specified target object at a given time. In addition, it addresses the use of signing and logging of events. Logging 
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of events here means "logging of actions" (not nessecarily logging of ALL actions) to be able to check "who did what". 
At least all "critical" actions (configurations etc.) shall be logged. 

Interface definitions addressing authentication and authorization are needed. Also note that layer A requires 
confidentiality. Layer B may provide this service. If not, layer A instead has to provide it itself. 

8.6.3 Common Services 

In common services we find the security infrastructure components: 

Directory (for storage of user information, certificates, etc.); 

PKI (Certificate Authority, Registration Authority, Public Key Certificate, etc.). 

Layer A relies on, and interacts with, the Common Services through distribution of certificates and keys, authentication 
of users, authorization, utilities for security administration (setting access rights), etc. 

Note that layer B does not necessarily interact with Common Services for security management purposes. The arrows in 
Figure 10 simply indicate the possible use of common services for configuration management. 



8.7 Software Management 



This subclause describes the software management process for third generation networks. Two main scenarios are 
considered: 

- Main SW Management Process : It covers requesting, acceptance, installation, monitoring, documenting, data 
base updating and feedback to the vendor for managing software. The sub-processes are valid for complete 
software releases and software patches for fault correction of the network elements and even element managers. 

Software Fault Management: Its emphasis is on network monitoring and handling faults which are caused by 
software malfunctions. 

8.7.1 Main Software Management Process 

The main focus is the management of new software releases and correction patches. Importance is placed integrating 
new software into a network with out causing unnecessary service disruptions and maintaining high levels of quality for 
the network. The Software Installation process is illustrated in Fig. A. 

1) Based on inputs form customer care interactions and marketing research, a network operator will establish new 
feature requirements. These requirements are sent to the vendor in the form of a feature request. 

2) The vendor deliveries a new software release/correction with the corresponding documentation and installation 
procedure to the network operator. It should be noted that when a network operator utilises equipment form 
more than one vendor, this process must run as multiple parallel processes. 

3) A service quality management department of the network operator receives and reviews the software. Upon 
approving the software for installation, the software is sent to the network provisioning department. 

4) Installation Task 

a) The software is installed in the appropriate network elements and/or element managers by network 

provisioning. 

b) Installation information is sent to the network maintenance and restoration department to inform them of 

pending changes in the network. 

c) Installation information is sent to the customer care centre to inform them of pending changes in the network. 

5) Installation Test and Validation 

a) Once the software has been installed, network provisioning must (should) perform test to check and ensure 
that the new software is working properly. 
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b) In addition to the checks that are performed by network provisioning, network maintenance and restoration 

could also detect malfunctions with in and outside the updated network element. 

c) Should network maintenance and restoration detect a problem with in the updated network element, then the 

network provisioning is informed to decide on further actions. 

6) Successful Installation Result 

a) Upon successful installation of the software, the service quality management departments is informed. 

b) A report is sent to network maintenance and restoration to inform them that the software will remain 

implemented in the network. At this point the documentation library and software data base must be 
updated. 

c) The network data management department is informed over the changes in the network. 

7) Negative Installation Result 

a) If the installation fails, network provisioning must perform a "fallback", i.e. remove the new software and 

insure that the network element is running properly on the old software. 

b) A report containing the negative results and finding will be sent to the service quality management and at the 

same time to the network maintenance and restoration. 

8) Once the installation procedure has been ended, the network maintenance and restoration department must 
closely monitor the affected network element to ensure proper performance. 

9) Service quality management will send feedback to the vendor as to the positive or negative results of the 
installation. 



Service Quality 
Management 




Network Provisioning 
(or Vendor Service) 



4b. Inst. -Info. 



8. Monitor 
Results 



Network Maintenance 
& Restoration 



Documentation 
Library 




Network 

Inventory 

Management 



7a. 
Fallbacld 



4d. Installation SW 



SW DB - Status 



Billing 



Mkt. Research 



Service 
Confij 



Customer 
Care Interface 



Prob. Handling 



4c. Inst.-Info. 



6c. DB-Info. 
5b. Event 



Network 

Data 

Management 



NMS or NEM or NE 



Figure 11 : IVIain Software IVIanagement Process 
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8.7.2 Software Fault Management. 



1) The network maintenance and restoration department detects an event or an alarm/fault from the network 
element. 

2) Problem solving and informing customer care 

a) The alarm is forwarded to the service problem resolution department for corrective actions and it is 

determined that the problem is caused by a software defect. 

b) In parallel the Customer Care Centre is informed, if the malfunction of the network may have impact on 

customers. 

3) The service problem resolution department informs problem handling and subsequently the customer care centre 
over service impairments with in the network. 

4) Problem handling reports to the service quality management department. The service disturbance is described 
with in the report. 

5) Service quality management checks the current software level of the affected network element with the network 
inventory management department. 

6) If major network disturbances still appear the Service Quality management decides to fallback to a stable SW 
version (maybe some time after a new SW installation) and requests Network Provisioning. 

7) a+b) :Network Provisioning performs the fallback and informs Network Maintenance and Inventory. 

8) Service quality management sends a request for a software correction to the vendor. 

9) The vendor sends a new software release or correction to the network operator. The rest of the procedure can 
followed in the main software management process. 



Fulfilment 



Assurance 



"Billing ^ 



Vendor 



Service Qt 



Network Provisioning 
(or Vendor Service) 




Fallback 
decision 
"anty r 



Management 

5. Retrieve ^ 4. Inform Quality 
Inventory Info 



Mkt. Research 



3. Report problem 



Customer 
Care Interface 

J 



7b. Fallback info 



Network Maintenance 
& Restoration 



Documentation 
Library 



7a. Fallback 



r^'i-il Network 
Inventory 
Management 



NMS or NEM or NE 




Figure 12: Software Fault Management 
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8.8 Configuration IVIanagement (including Equipment Inventory) 

A variety of components will make up an operator's actual implementation of a 3G network. Since it is an explicit goal 
of the standardisation effort within 3GPP to allow mix and match of equipment from different vendors, it is expected 
that many networks will indeed be composed of multiple vendors' equipment. For an operator to be able to properly 
manage this diverse network, in order to provide the quality of service expected by his customers, it is essential to 
standardise the configuration management for 3G systems at least to an extent that the operation of the multi-vendor 
network will be possible effectively and efficiently. Therefore, a new work item is proposed for Configuration 
Management of 3G systems as described below. Within the scope of this work item, a distinction has to be made 
between those aspects of the configuration management targeting single network elements (NE management level) and 
those that are also, or exclusively, relevant for some part or the entire network (Network Management level). 

8.9 Accounting Management 

3G TS 32.105 "3G call event data" is based on the requirements specified in 3G TS 22.115. The main content of this 
new specification is: 

Layout and formats of raw call and event data for the 3G switching nodes (circuit and packet switched); 

Data generation dependent on call states and TS 22. 115 service requirements; 

Formal description of the call and event data records in ASN. 1 and definition of a file transfer mechanism (FTP). 



Methodology 



9.1 Documentation 

The methodology followed for the specification of UMTS Management is structured in the following levels and steps: 

9.1 .1 UMTS Management Overall Architecture, Functionality/Processes 
and Principles specification 

The UMTS Management Overall Architecture, Functionality/Processes and Principles are specified in the present 
document. 

9.2 Tools and Methods 

The tool and method to be used for documenting Interface Specifications will be UML. 
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Annex A (normative): 

UMTS Management Application Layer Protocols 

The valid Management Application Layer Protocols for UMTS are: 

- CMIP 

- SNMP 

- CORBA HOP 

The valid Application Layer Protocols for Bulk Transfer are: 

- FTAM 

- ftp 

- tftp 
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Annex B (normative): 

UMTS Management Network Layer Protocols 

The valid Network Layer Protocols for the Management of UMTS are: 

- IP 

- X.25 
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Annex C (normative): 

UMTS Management IRP Solution Sets 

The valid IRP Solution Sets for the Management of UMTS are: 

- CMIP/GDMO 

- CORBA/IDL 
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Annex D (informative): 
Change history 



This annex lists all change requests approved for this document since the specification was first approved by 3GPP 
TSG-SA. 
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